
------------------------------------------

## 질문:

`1. stage_2_task_A_B_C_Gemini_update.yml`은 청구권을 식별하는 작업(task_B, task_C)을 지시하는 프롬프트를 기존에 비해 개선한 것이다. 지금 다루는 사건의 고객 상담 문서(client_meeting.md)와 정보화된 모든 증거문서들(evidence_all.json)을 입력받아 `1. Stage_1.yaml`을 실행하여 얻은 결과물들이 source에 존재한다. 

이제 이 결과물들 및 client_meeting.md를 이용하여 stage 2 작업을 `1. stage_2_task_A_B_C_Gemini_update.yml`을 통해 실행하여 얻은 결과물이 
- claim_identification_view.json
- claims_identified_case_type.json
- claims_identified.json
이다. 

특히 claims_identified.json과 claims_identified_case_type.json는 식별한 청구권들 및 각 청구권들이 어떤 사건 유형에 해당하는지를 판별한 결과물이다. 

그런데, 20년 이상 경력을 지닌 대한민국 최고 수준의 변호사는 현재 다루고 있는 사건에 대해 아래와 같이 청구권을 식별할 수 있다고 주장한다.
---
1. {"claim_title":"물품대금 청구","plaintiffs":["강용원"],"defendants":["김선웅"],"claim_statement":"원고 강용원은 피고 김선웅을 상대로 물품대금 청구를 할 수 있다."}

2. {"claim_title":"물품대금 청구","plaintiffs":["강용원"],"defendants":["오민한"],"claim_statement":"원고 강용원은 피고 오민한을 상대로 물품대금 청구를 할 수 있다."}

3. {"claim_title":"소유권이전등기말소 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 소유권이전등기말소 청구를 할 수 있다."}

4. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["이문호"],"claim_statement":"원고 강용원은 피고 이문호를 상대로 부당이득반환 청구를 할 수 있다."}

5. {"claim_title":"부당이득반환 청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 부당이득반환 청구를 할 수 있다."}

6. {"claim_title":"건물철거 및 토지인도 청구","plaintiffs":["강용원"],"defendants":["박성희"],"claim_statement":"원고 강용원은 피고 박성희를 상대로 건물철거 및 토지인도 청구를 할 수 있다."}

7. {"claim_title":"근저당권설정등기말소 청구","plaintiffs":["강용원"],"defendants":["대한은행"],"claim_statement":"원고 강용원은 피고 대한은행을 상대로 근저당권설정등기말소 청구를 할 수 있다."}

8. {"claim_title":"사해행위취소 청구","plaintiffs":["강용원"],"defendants":["오민한"],"claim_statement":"원고 강용원은 피고 오민한을 상대로 사해행위취소 청구를 할 수 있다."}

9. {"claim_title":"건물인도 청구","plaintiffs":["양정숙"],"defendants":["박광윤"],"claim_statement":"원고 양정숙은 피고 박광윤을 상대로 건물인도 청구를 할 수 있다."}

10. {"claim_title":"부당이득반환 청구","plaintiffs":["양정숙"],"defendants":["박광윤"],"claim_statement":"원고 양정숙은 피고 박광윤을 상대로 부당이득반환 청구를 할 수 있다."}

11. {"claim_title":"임차권확인 청구","plaintiffs":["양정숙"],"defendants":["윤건우"],"claim_statement":"원고 양정숙은 피고 윤건우를 상대로 임차권확인 청구를 할 수 있다."}
---

이 변호사가 제시하는 청구권과 claims_identified.json이 제시하는 청구권들 사이에 약간의 불일치가 존재한다. 특히, claims_identified.json에서는 '피고: 이문호'와 '피고:박성희'를 상대로 한 '부당이득반환 청구'를 제시하지 않고 있다. 그리고 claims_identified.json는 '피고: 이문호'에 대해 '원고: 강용원'이 '건물철거 및 토지인도 청구'를 제시하고 있으나 위에 언급한 변호사는 이에 대한 청구 내용은 다루지 않고 있는 것으로 보인다. 

`1. stage_2_task_A_B_C_Gemini_update.yml`를 실행한 결과와 대한민국 최고 수준의 변호사가 제시한 청구권 식별 결과에 차이가 발생한 이유는 무엇인지 매우 심도 깊게 분석하여 그 원인을 파악하라. 



-------------------------------------------

## 답변:

결론부터 말하면, 이번 불일치는 단순한 “LLM의 실수”라기보다, **Stage 1에서 만들어진 구조화 데이터의 표현 방식**과 **Stage 2 프롬프트가 채택한 청구권 진입 규칙**이 결합되어 생긴 **구조적 산출 편향**입니다. 특히 이번 사건에서 문제된 성수동 분쟁 부분은, 변호사는 여러 사실을 종합하여 권리구제를 재구성했지만, 파이프라인은 **명시적으로 앵커링된 fact 중심**으로만 청구를 세우도록 설계되어 있어, 결과적으로 `부당이득반환 청구`는 빠지고, 대신 `건물철거 및 토지인도`, `건물퇴거`, `등기말소`처럼 **사건행위와 직접 연결된 주문형 청구**가 상대적으로 더 쉽게 산출되었습니다. 그 결과 `claims_identified.json`은 이문호·박성희 상대 `부당이득반환청구`를 넣지 않았고, 반대로 강용원 대 이문호 `건물철거 및 토지인도청구`, 강용원 대 박성희 `건물퇴거청구`를 후보로 식별했습니다. 또한 이들 항목은 스스로도 확정 청구가 아니라 `completeness` 태그가 붙은 “주장 후보”로 남아 있습니다.  

가장 중요한 원인은 **event-level 분해와 document-level 계산객체가 다시 뒤섞인 것**입니다. Stage 1의 `evidence_event_candidates.json`은 E-006 문서에서 **(i) 성수동 대지 임대차**와 **(ii) 성수동 상가 매매**를 분명히 별개의 사건행위로 분해해 두었습니다. 즉, 이 단계에서는 “대지 임대”와 “건물 매매”가 구별되어 있었습니다.  그런데 같은 E-006에 대한 `evidence_indexed.json`의 `legal_calculation_object`는 문서 단위로 단 하나만 남았고, 그 값이 `transaction_type="매매"`, `sale_price="200,000,000원"`, `consideration_breakdown=["매매대금 2억 원"]`으로 저장되었습니다. 다시 말해, 문서 안에 함께 들어 있던 **임대차 정보는 event-level에서 분리되었지만**, downstream에서 참조되는 계산객체는 **매매 정보 하나로 문서 전체를 대표**하게 되었습니다. 

이 왜곡은 실제로 downstream 뷰에 나타납니다. `claim_identification_view.json`에서 F-032는 명백히 “이문호가 박성희에게 성수동 대지를 임대하였다”는 임대차 fact인데도, 그 `property_transaction`에는 `transaction_type="매매"`와 `sale_price="200,000,000원"`이 들어가 있습니다. 즉, **대지 임대차 fact가 건물 매매 metadata를 상속**받은 것입니다. 같은 현상은 다른 곳에서도 반복되는데, F-014는 “강용원이 정유심으로부터 성수동 대지 3/5 지분을 증여받았다”는 fact임에도 `property_transaction.transaction_type="매매"`, `registration_date="2024-10-05"`를 달고 있습니다. 이는 event-level 사실 위에 later-stage document-level metadata가 덮어씌워졌다는 강력한 증거입니다. 

그리고 이 오염이 발생한 이유는 Stage 1의 후반 규칙 자체에 있습니다. `Fact_Ledger_base.json`을 만드는 Task_D1은, BO에 대응하는 `legal_calculation_object`를 새로 만들지 말고 **linked evidence의 `legal_calculation_object`만 최소 병합**하라고 명시합니다. 더구나 BO의 `Action`, `Subject`, 개별 증거의 다른 정보로 새 계산필드를 창작하는 것도 금지합니다. 따라서 E-006처럼 한 문서 안에 복수의 사건행위가 있어도, 그 문서에 단 하나의 계산객체만 있으면 downstream fact/view는 그 단일 객체의 성격을 강하게 상속받게 됩니다. 바로 이 설계가 성수동 대지 임대차와 성수동 건물 매매를 다시 평면화했습니다.  

두 번째 원인은, **Stage 2가 변호사식 법률구성보다 “source_fact_ids로 앵커링 가능한가”를 더 우선**하도록 되어 있다는 점입니다. 업데이트된 프롬프트는 분명 `client_meeting.md`를 1차 자료로 놓지만, 동시에 `source_fact_ids`는 반드시 `claim_identification_view.json.items[*].fact_id`에서만 뽑으라고 못 박고 있습니다. 또 `client_meeting.md`나 `client_goal.json`이 피고 범위를 보강하더라도, `claim_identification_view.json` 안에서 그 사람을 앵커링할 fact가 없으면 `identified_entry_gate`를 충족하지 못한다고 규정합니다. 즉, **원자료로부터 법률적으로 충분히 추론 가능한 청구**라도, 그 추론을 지탱할 구조화된 fact anchor가 약하면 pipeline은 그 청구를 세우기 어렵습니다. 인간 변호사는 “경매의 효력 문제 → 소유권 귀속 문제 → 무권원 점유/사용수익 → 부당이득반환”으로 넘어가지만, 이 프롬프트는 그렇게 넓게 넘어가도록 설계되지 않았습니다.    

이 점 때문에, **이문호·박성희 상대 부당이득반환청구가 누락된 이유**가 설명됩니다. 성수동 가지(branch)에서 구조화된 fact는 주로 `경매 낙찰(F-027)`, `근저당권 설정(F-028)`, `인도명령에 의한 대지 인도(F-029)`, `건물 신축(F-031)`, `대지 임대(F-032)`, `건물 매매(F-033)`입니다. 즉, 사건행위는 풍부하지만, “무권원 사용수익으로 이득을 취하였다”, “차임 상당 이득을 반환해야 한다”, “법률상 원인 없는 이득”이라는 형식의 **직접적인 이득 귀속 fact**는 구조화되어 있지 않습니다. 반면 박광윤에 대해서는 `유치권 행사하며 임대`, `계속 점유`, `유치권 소멸청구 통지` 등 점유·사용·이득과 연결되는 fact가 비교적 직접적으로 정리되어 있어서 `부당이득반환청구`가 더 쉽게 식별되었습니다. 이는 출력 구조에 기초한 제 추론이지만, 상당한 설명력을 가집니다.    

세 번째 원인은, 이 파이프라인이 성수동 부분에서 **“가장 명시적인 사건행위의 행위자에게 가장 가까운 구제수단”을 붙이는 경향**을 보인다는 점입니다. 성수동 가지의 시간축을 보면, 이문호는 경매로 대지를 취득하고(F-027), 대한은행에게 근저당권을 설정하고(F-028), 인도명령으로 대지를 인도받고(F-029), 그 위에 건물을 신축하고(F-031), 박성희에게 대지를 임대하고(F-032), 건물을 매도합니다(F-033). 따라서 모델 입장에서는 “건물을 신축한 사람 = 이문호”라는 사실이 매우 직접적이므로, 그에게 `건물철거 및 토지인도청구`를 붙이기가 쉬웠습니다. 반면 변호사는 여기서 한 걸음 더 나아가, 현재의 점유·귀속 구조를 기준으로 **박성희 상대 건물철거 및 토지인도**, 그리고 **이문호·박성희 각자에 대한 부당이득반환**으로 재배치한 것으로 보입니다. 즉, 변호사는 “누가 어떤 행위를 했는가”보다 “현재 누가 어떤 법률상 이익을 보유하는가”를 중심으로 구제를 설계했고, 파이프라인은 그 반대로 갔습니다.   

네 번째 원인은, **약한 근거의 후보도 completeness 태그를 붙여 유지하도록 허용한 규칙**입니다. 업데이트 프롬프트는 identified entry gate만 넘으면, 4문턱 중 일부가 불명확하더라도 identified_claims에 넣고 `completeness`로 관리할 수 있도록 허용합니다. 실제로 C-007부터 C-010까지는 모두 `RIGHT_GENERATION_REVIEW` 등을 단 `주장 후보`입니다. 그런데 이 후보들을 떠받치는 핵심 fact 중 F-020(오민한에 대한 4억 변제)과 F-031(이문호의 성수동 건물 신축)은 `credibility="low"`이고 증거도 비어 있습니다. 그럼에도 프롬프트는 저신빙성 fact라도 청구유형 특정과 fact 연결이 가능하면 후보로 남길 수 있게 설계되어 있습니다. 따라서 변호사라면 아직 분리·정교화했을 가지가, 이 파이프라인에서는 후보 청구권으로 먼저 산출된 것입니다.   

다섯 번째 원인은, **업데이트 프롬프트의 “원고 x 피고 모든 조합이 10개 이상 도출되었는지”라는 검증 항목**입니다. 최종 `claims_identified.json`에는 정확히 10개의 청구가 들어 있습니다. 이것만으로 인과관계를 단정할 수는 없지만, 적어도 **마진이 약한 chain도 탈락시키기보다 유지하려는 방향으로 작동했을 강한 정황**은 있습니다. 다시 말해, 파이프라인은 “변호사처럼 소수의 정교한 청구를 고르기”보다 “구조적으로 만들 수 있는 후보를 가능한 한 빠짐없이 유지하기” 쪽으로 튜닝되어 있습니다.  

여기에 더하여, `client_goal.json` 자체가 성수동 분쟁을 **경매 공신력 문제, 이문호 명의 이전, 건물 신축, 박성희 인수**라는 서사로 요약하고 있습니다. 즉, Stage 1이 client meeting을 구조화하는 순간부터 성수동 부분의 핵심 축이 “부당이득”보다 “경매·소유권·신축·인수” 쪽으로 압축되어 있습니다. 적어도 현재 직접 확인 가능한 구조화 요약본 수준에서는 그렇습니다. 그러므로 Stage 2가 이후 동일 사건을 읽을 때, registry cancellation·mortgage cancellation·removal/delivery 계열로 흘러가는 것은 자연스러운 결과였습니다.

또 하나 중요한 점은, 이번 파이프라인에서 **사해행위취소 관련 정교한 확장 로직은 사실상 신림동-오국한-오민한 가지에만 집중**되어 있었다는 사실입니다. `actio_case_signals.json`과 `claim_identification_view.json`의 사건맥락은 관련 BO와 관련 증거를 `bh7, bh8, bh13, bh30` 및 `E-003, E-008, E-014, E-024`로 특정하고 있고, 대상 부동산도 신림동 상가입니다. 따라서 업데이트 프롬프트가 가지고 있는 “수익자 chain, 후행 담보권자 chain, 다수 피고 조합”의 정교한 actio 확장 논리는 주로 그 가지에서 작동했고, 성수동 Lee/Park branch에는 같은 밀도의 구조적 보조가 제공되지 않았습니다.   

이제 질문하신 세 쟁점을 각각 정리하면 이렇습니다.

첫째, **왜 `피고: 이문호` 상대 `부당이득반환 청구`가 누락되었는가**.
이문호에 대해서는 구조화 fact가 `경매낙찰 → 소유권이전등기 → 인도명령 → 건물신축 → 후속 임대/매도`로 잡혀 있습니다. 그런데 pipeline은 이 연쇄를 “경매 효력 문제로 인한 소유권이전등기말소”, “후속 근저당권설정등기말소”, “신축 건물 철거 및 토지인도”로 잘게 나누는 데 유리한 구조를 가지고 있었습니다. 반면 `부당이득반환`은 “무권원 이득 귀속”이라는 한 단계 높은 법률구성을 필요로 하는데, 그를 직접 지시하는 fact anchor가 약했습니다. 그래서 이문호 branch에서는 `C-007`, `C-008`, `C-009`가 남고, `부당이득반환청구`는 생기지 않은 것입니다. `claims_identified.json` 자체도 이 세 청구를 확정이 아니라 후보로만 남기고 있습니다.  

둘째, **왜 `피고: 박성희` 상대 `부당이득반환 청구`가 누락되었는가**.
박성희에 관하여 upstream event layer는 분명 `대지 임대차`와 `건물 매매`를 구분했습니다. 그러나 downstream에서는 F-032 임대차 fact가 E-006의 매매 metadata를 함께 달고 내려오면서, 박성희는 “대지를 임차한 자”이자 동시에 “건물을 매수한 자”로 보이되, 그 중 후자가 더 강하게 구조화되었습니다. 그래서 결과는 `건물퇴거청구(C-010)`로 수렴했고, `대지 점유/사용수익에 대한 부당이득반환`이라는 별도 청구는 분리되지 않았습니다. 이 역시 lawyer-style doctrinal allocation이 아니라 event-anchor matching의 산물입니다.    

셋째, **왜 오히려 `피고: 이문호` 상대 `건물철거 및 토지인도 청구`가 생성되었는가**.
이문호는 F-031에서 “성수동 대지 위에 성수동 건물을 신축한 자”로 직접 잡혀 있습니다. 그리고 Stage 2는 동일 가지에서 “행위자-목적물-직접 구제”를 붙이는 경향이 강합니다. 따라서 현재 점유자나 수익귀속자를 기준으로 구제를 설계한 변호사와 달리, 모델은 “건물을 세운 사람 = 철거청구의 1차 피고”로 연결했습니다. 다만 이 청구조차 `RIGHT_GENERATION_REVIEW`가 붙어 있는 후보일 뿐이고, 파이프라인 스스로도 완전히 확정하지는 못했습니다.   

이와 연동하여, **왜 박성희에 대해서는 `건물퇴거청구`가 나왔는가**도 설명됩니다. F-033은 “이문호가 박성희에게 성수동 건물을 대금 2억 원에 매도하였다”는 매우 직접적인 fact입니다. 그러니 현재 건물 귀속자 내지 점유 주체로서 박성희를 잡아 `건물의 명도/퇴거` 계열 청구로 연결하는 것은 파이프라인 입장에서는 자연스럽습니다. 이후 `claims_identified_case_type.json`은 이 선택을 다시 표준사건명으로 번역하여 C-010을 `건물의 명도(인도)의 소`로, C-009를 `토지의 인도를 구하는 소`로 분류합니다. 즉, downstream case-type 단계는 upstream의 remedy allocation을 바로잡지 못하고 그대로 제도권 표준명칭으로만 치환합니다.  

정리하면, 이번 차이의 본질은 다음 한 문장으로 압축됩니다.
**대한민국 최고 수준의 변호사는 여러 사실을 종합하여 “권리귀속–침해상태–현존 이익”을 기준으로 청구를 재배치했지만, 현재 파이프라인은 Stage 1에서 부분적으로 오염된 structured fact/view를 전제로, source_fact_id로 명시적으로 앵커링 가능한 사건행위에 가장 가까운 주문형 청구를 먼저 산출하도록 설계되어 있다**는 점입니다. 그 결과 성수동 branch에서는 `부당이득반환청구` 같은 종합적 법률구성은 약해지고, `소유권이전등기말소`, `근저당권설정등기말소`, `건물철거 및 토지인도`, `건물퇴거` 같은 직접 사건행위 대응형 청구가 상대적으로 쉽게 선택된 것입니다.    

한마디로, **업데이트 프롬프트가 나빠서 생긴 문제라기보다, 업데이트된 프롬프트조차도 여전히 “Stage 1의 구조화 방식”과 “fact-anchor 중심의 진입 규칙”을 그대로 상속받고 있어서, 인간 변호사의 교의적 종합판단을 재현하지 못한 것**입니다. 핵심 병목은 prompt wording보다 **data contract**에 있습니다.


--------------------------------------

## 질문:

지금 위에서 제시한 원인 분석에 따르면 stage 2의 프롬프트에서 stage 1에서의 결과물을 사용하는 방법, 그리고 stage 1 결과물 그 자체의 특징들로 인해서 이러한 결과가 벌어진 것으로 보인다. 

그렇다면, 문제해결을 위해서 특정한 규칙들을 1. stage_2_task_A_B_C_Gemini_update.yml에 추가·수정하는 것보다 stage 1 작업지시 prompt를 수정하여 stage 1 결과물들의 특징을  고도화하는 것이 우선일 것으로 생각된다. stage 1 프롬프트부터 개선하는 것이 바람직한가? 아니면 stage 2 프롬프트를 개선하는 것만으로도 위에서 제시된 청구권 식별 불일치 문제를 충분히 해결할 수 있고, 더 나아가 다른 민사소송 사건들의 경우에도 일반성을 잃지 않도록 할 수 있는가? 

--------------------------------------


예. 제 판단으로는 **Stage 1 프롬프트를 먼저 고치는 것이 우선**입니다. Stage 2만 손보는 방식으로도 이번 사건의 일부 불일치는 줄일 수 있으나, 그것만으로는 충분하지 않고, 다른 민사사건으로 일반화될수록 오히려 불안정성이 커질 가능성이 높습니다. 이 결론은 이번 사건에서 드러난 오류가 **청구권 추론 단계의 법률판단 오류**라기보다, 그보다 앞선 단계에서 이미 **사건행위 단위 정보가 문서 단위 metadata에 의해 오염되는 구조**에서 발생했기 때문입니다. E-006에서 event-level로는 `성수동 대지 임대차`와 `성수동 상가 매매`가 분해되어 있었지만, `evidence_indexed.json`의 문서 단위 `legal_calculation_object`는 `매매` 하나만 남겼고, 그 결과 downstream에서 임대차 fact가 매매 metadata를 상속받았습니다. 이는 Stage 1 산출물의 구조 문제이지, Stage 2의 claim-selection 규칙만의 문제는 아닙니다.

조금 더 엄밀하게 말하면, 이번 문제는 두 층으로 나뉩니다.

첫째 층은 **표현(representation) 오류**입니다.
Stage 1은 한 문서 안에 복수 사건행위가 있어도, 후반부에서 BO나 Fact에 연결되는 계산객체를 **문서당 하나의 `legal_calculation_object`**로 유지하는 방향을 택했습니다. 게다가 Task_D1은 linked evidence의 base `legal_calculation_object`만 병합하고, BO의 `Action`, `Subject`, 개별 event 정보를 사용해 새 계산필드를 만들지 말라고 명시합니다. 이 규칙 때문에 event-level 구별이 downstream에서 다시 납작해졌습니다. 이런 구조에서는 Stage 2가 아무리 정교해도, 입력 자체가 이미 “대지 임대차 fact + 건물 매매 metadata”처럼 꼬여 있으면, 후속 청구식별은 계속 오염될 위험이 큽니다.

둘째 층은 **추론(inference) 보수성**입니다.
Stage 2는 `client_meeting.md`를 중시하더라도, 최종적으로는 `source_fact_ids`를 `claim_identification_view.json.items[*].fact_id`에 앵커링하도록 강제하고, 구조화된 fact anchor가 약하면 청구를 세우지 않도록 설계되어 있습니다. 그래서 변호사처럼 여러 사실을 묶어 `부당이득반환청구`로 재구성하기보다, 구조적으로 직접 보이는 `등기말소`, `철거`, `인도`, `퇴거` 쪽으로 먼저 수렴합니다. 이 부분은 Stage 2의 문제이지만, 그 작동방식은 Stage 1 산출물의 질에 강하게 종속됩니다.

따라서 우선순위를 정하면 다음과 같습니다.

**1순위는 Stage 1 개선**입니다.
이유는 간단합니다. Stage 1이 잘못 압축한 정보를 Stage 2가 뒤에서 복원하는 방식은 본질적으로 사후보정입니다. 사후보정은 특정 사건에서는 먹혀도, 일반성을 잃기 쉽습니다. 특히 민사소송 사건은 문서 하나에 여러 법률관계가 함께 들어 있는 경우가 흔합니다. 매매계약서 하나에 임대차 특약, 담보부 인수, 사용수익 관계, 점유이전, 부담해소 조항이 같이 들어갈 수 있습니다. 이런 상황에서 문서 단위 단일 계산객체를 유지한 채 Stage 2만 더 똑똑하게 만들면, 결국 Stage 2는 매번 “이 문서의 어느 조항이 어느 event에 대응하는가”를 다시 추정해야 합니다. 그러면 구조는 점점 heuristic-heavy해지고, 사건마다 예외 규칙이 누적됩니다. 이번 사건에서 드러난 E-006 문제가 바로 그 전형입니다.

**Stage 2만 개선하는 접근은 보조수단으로는 유효하지만, 주된 해결책으로는 부적절**합니다.
왜냐하면 Stage 2가 해야 할 일은 원래 “권리구제 단위의 법률구성”이지 “오염된 event/property metadata 복원”이 아니기 때문입니다. Stage 2에 복원 로직을 계속 얹으면, 청구식별 프롬프트가 점점 Stage 1의 정규화 실패를 뒤처리하는 복구 프롬프트로 변질됩니다. 그렇게 되면 다른 사건들, 예컨대 하나의 문서에 매매와 채무인수, 일부말소, 임차권 양수, 공사대금 정산이 섞여 있는 유형에서 규칙 충돌이 더 심해질 수 있습니다. 즉, 이번 사건에서는 Stage 2가 “부당이득반환청구도 열어라”라고 지시받으면 어느 정도 보정할 수 있겠지만, 다른 사건에서는 오히려 과잉식별이나 중복식별이 늘어날 위험이 큽니다. 이것은 제 추론이지만, 현재 구조와 프롬프트 계약을 보면 상당히 강한 추론입니다.

정리하면, 질문하신 두 선택지 중에서는 다음 판단이 더 타당합니다.

**Stage 1을 먼저 개선하고, Stage 2는 그 다음에 최소한으로 보정하는 것이 바람직합니다.**
Stage 2만 손보는 것으로는 이번 사건의 특정 불일치 몇 개를 줄일 수는 있어도, 일반적 해법이 되기 어렵습니다. 반대로 Stage 1을 고치면, 이번 사건뿐 아니라 다른 사건에서도 downstream 전반의 품질이 같이 올라갑니다. `BO.json`, `Fact_Ledger_base.json`, `claim_identification_view.json`, `claims_identified.json` 전체가 더 안정해집니다.

다만 여기서 중요한 것은, **Stage 1만 고치고 Stage 2를 그대로 두면 충분하냐**는 별개의 문제입니다. 제 판단은 **아니오**입니다. Stage 1 우선이 맞지만, 최종적으로는 Stage 2도 손봐야 합니다. 이유는 Stage 2 프롬프트 자체가 현재 다음과 같은 성향을 갖고 있기 때문입니다.

하나는, 구조화된 fact anchor가 약하면 변호사식 종합구성을 잘 하지 못한다는 점입니다.
다른 하나는, `identified_claims`에 completeness 태그를 붙여 약한 후보를 유지하는 방식이라, 이번처럼 `건물철거 및 토지인도청구` 같은 청구가 후보로 남기 쉽다는 점입니다. 실제 `claims_identified.json`의 성수동 관련 청구들은 대부분 completeness 태그가 붙은 후보입니다. 즉, Stage 1이 바로잡혀도 Stage 2가 여전히 “직접 보이는 event-based remedy”를 과선호하면, 변호사가 구성하는 `부당이득반환청구` 같은 청구는 여전히 과소식별될 수 있습니다.

그래서 실무적으로는 다음 순서가 가장 합리적입니다.

**첫째, Stage 1을 고쳐 event-level 객체와 calculation 객체를 일치시키십시오.**
핵심은 문서 단위 `legal_calculation_object`를 유지하더라도, 적어도 **event candidate별 transaction/encumbrance/value sub-object**가 별도로 있어야 한다는 점입니다. E-006처럼 임대차와 매매가 섞인 문서는 문서 전체를 대표하는 하나의 계산객체가 아니라, 각 event에 귀속된 계산객체를 가져야 합니다. 이 부분이 해결되면 F-032 같은 fact가 더 이상 `transaction_type="매매"`를 상속받지 않게 됩니다.

**둘째, Stage 2는 Stage 1이 고도화된 뒤에 ‘법률구성 규칙’만 보강하십시오.**
즉, Stage 2는 데이터 복원기가 아니라, 청구구성기여야 합니다. 여기서 보강해야 할 것은 “현재 점유·사용수익·무권원 이익 귀속이 구조화되어 있으면 부당이득반환청구도 병렬적으로 검토하라”, “동일 목적물 cluster에서 등기말소청구와 부당이득반환청구, 철거·인도청구는 상호배타적으로 하나만 고르지 말고 병렬 검토하라” 같은 **claim-construction 규칙**입니다. 이것은 Stage 2의 몫이 맞습니다. 다만 그 전제가 Stage 1에서 사건행위와 계산정보가 깨끗하게 분리되어 있어야 합니다.

따라서 제 최종 답변은 다음과 같습니다.

**우선순위 측면에서는 Stage 1 프롬프트부터 개선하는 것이 맞습니다.**
이번 문제의 근원은 Stage 2의 미세한 규칙 부족보다, Stage 1 산출물의 구조적 표현 방식에 있습니다. Stage 2만 개선하는 방식은 이번 사건에 대한 사후 패치로는 가능하지만, 다른 민사사건까지 일반화하면 brittle해질 가능성이 큽니다.
다만 **최종 해결은 “Stage 1 우선 개선 + Stage 2 제한적 보정”의 2단계 접근**이어야 합니다. Stage 1이 데이터 구조를 바로잡고, Stage 2가 그 위에서 변호사식 청구 병렬구성을 더 잘 하도록 조정하는 방식이 가장 일반성과 안정성을 동시에 확보합니다.



-------------------------------------

## 질문: 

우선 "Stage 1에서 반드시 고쳐야 할 규칙들"을 모두 제시하라. 고쳐야 할 항목들의 개수에 제약은 없다. 

-------------------------------------

## 답변: 

그렇습니다. 지금 단계에서는 **Stage 2보다 먼저 Stage 1 프롬프트를 고쳐야 하고**, 그중에서도 단순 문구 보정이 아니라 **산출물의 데이터 계약(data contract) 자체를 바꾸는 수준의 수정**이 필요합니다.

핵심은 다음입니다.
현재 Stage 1은 한편으로는 Task_B2에서 “한 문서에 복수의 행위가 있으면 반드시 여러 candidate로 분리”하라고 요구하면서도, 다른 한편으로는 Task_B1에서 `legal_calculation_object`를 “문서당 0개 또는 1개만 허용”하고, Task_D1에서는 그 문서 단위 계산객체만을 linked evidence 기준으로 BO/Fact에 최소 병합하도록 설계했습니다. 이 조합 때문에 event-level 분해가 downstream에서 다시 문서 단위 metadata로 평탄화됩니다. E-006은 `성수동 대지 임대차`와 `성수동 상가 매매`를 별도 event로 분해했지만, `evidence_indexed.json`에서는 문서 단위 `legal_calculation_object`가 `매매` 하나로만 잡혀 있습니다.   
따라서 아래의 수정들은 “있으면 좋은 개선”이 아니라, **반드시 고쳐야 할 규칙들**입니다.

---

## 1. Task_B1의 `legal_calculation_object`를 “문서당 1개”로 두는 규칙을 폐기해야 한다

현재 Task_B1은 `legal_calculation_object`에 대해 “문서당 0개 또는 1개만 허용, 후보가 둘 이상이면 가장 직접적인 1개만 남긴다”고 지시합니다. 이 규칙이 바로 E-006 유형의 오염을 만들어냅니다. `계 약 서` 한 문서에 대지 임대차와 건물 매매가 함께 있어도, 결국 매매 하나만 대표 metadata가 되어 downstream 전체를 오염시킵니다. 실제 `evidence_indexed.json`의 E-006은 `key_facts`에 임대차와 매매를 같이 적어 두고도, `legal_calculation_object`는 `transaction_type="매매"`, `sale_price="200,000,000원"`만 남겨 두었습니다.  

### 반드시 바꿔야 할 방향

`evidence_indexed.json`의 `legal_calculation_object`를 문서 대표 객체로 유지하지 말고, 다음 둘 중 하나로 바꿔야 합니다.

첫 번째 방안은 가장 권장되는 방식인데, **Task_B1에서 계산객체를 아예 문서 수준에서 만들지 않는 것**입니다. 문서 카탈로그는 문서 카탈로그답게 `title`, `doc_type`, `key_facts`, `key_dates`, `key_amounts`, `key_parties`, `source_pointer`까지만 유지하고, 거래유형/대가/등기정보/담보정보/차임정보는 전부 event-level로 내리는 것입니다.

두 번째 방안은 차선책으로, 문서 수준에 남기되 **`legal_calculation_objects` 배열**로 바꾸는 것입니다. 즉 문서 안의 복수 transaction cluster를 병렬 저장하고, 각 객체마다 `object_anchor`, `locator_hint`, `transaction_type`, `sale_price`, `lease_terms`, `encumbrance_terms` 등을 별도로 붙여야 합니다.

이 둘 중 어느 방식을 택하든, **문서 수준 단일 계산객체는 폐기**해야 합니다.

---

## 2. Task_B2의 event candidate에 “event-level calculation sub-object”를 반드시 넣어야 한다

현재 Task_B2는 event를 잘게 분해하지만, 그 출력은 `event_kind`, `participants`, `object_spec`, `amount`, `event_date`, `support_locators` 정도에 머물러 있습니다. 즉, 사건행위는 event-level인데, 계산정보는 여전히 문서 카탈로그 쪽에 남아 있습니다. 이 구조가 가장 큰 병목입니다. 

### 반드시 추가해야 할 필드

각 `event_candidates[]` 내부에 적어도 아래 중 해당되는 것을 넣어야 합니다.

* `event_legal_calculation_object`

  * `transaction_type`
  * `transaction_date`
  * `sale_price`
  * `consideration_breakdown`
  * `registration_date`
  * `registry_office`
  * `registry_receipt_no`
  * `registry_recorded_transfer_date`
  * `lease_deposit_amount`
  * `monthly_rent_amount`
  * `lease_term_start`
  * `lease_term_end`
  * `encumbrance_kind`
  * `encumbrance_holder`
  * `registered_max_amount`
  * `market_value_at_act`
  * `market_value_at_close`

중요한 점은 이것이 “있을 때만” 들어가는 보조 필드가 아니라, **event가 금전·처분·등기·임대차·담보와 관련될 때는 필수 추출 대상**이어야 한다는 것입니다.

E-006이라면 최소한 다음 두 event가 따로 정보를 가져야 합니다.

* E-006-EC-01: 임대차 / 성수동 대지 / 보증금 3억 / 월 300만
* E-006-EC-02: 매매 / 성수동 상가 / 매매대금 2억

이것이 없으면 Task_C와 Task_D1은 계속 문서 단위 metadata를 참조하게 됩니다.  

---

## 3. Task_C에서 BO를 만들 때 문서 카탈로그의 계산객체를 보조로만 쓰고, event-level 계산객체를 1차로 쓰게 바꿔야 한다

현재 Task_C는 `evidence_event_candidates.json`으로부터 BO를 만들지만, `evidence_indexed.json`은 “증거 authority 및 evidence metadata 확인용”으로만 쓴다고 하면서도, 실제 downstream 구조에서는 BO와 Fact가 linked evidence의 문서 단위 계산객체를 강하게 상속하게 됩니다. 그 결과 BO는 event-level인데 계산정보는 document-level이 됩니다. 

### 반드시 바꿔야 할 규칙

Task_C에 명시적으로 다음을 추가해야 합니다.

* evidence 기반 BO를 생성할 때, **해당 BO의 계산정보는 대응하는 event candidate의 `event_legal_calculation_object`를 1차 소스로 사용**한다.
* `evidence_indexed.json`의 문서-level 계산정보는 **authority fallback**으로만 사용한다.
* event-level 계산정보와 문서-level 계산정보가 충돌하면 **event-level을 우선**한다.
* 하나의 문서에서 여러 BO가 파생될 경우, 각 BO는 **자기 event candidate의 계산정보만 상속**하고, 같은 문서의 다른 event 계산정보를 절대 상속하지 않는다.

이 한 줄이 없으면, Stage 1을 아무리 앞단에서 개선해도 Task_C가 다시 document-level flattening을 일으킬 수 있습니다.

---

## 4. Task_D1의 “linked evidence의 `legal_calculation_object`만 병합” 규칙을 폐기하거나 대폭 수정해야 한다

현재 Task_D1은 가장 직접적으로 문제를 고정시키는 단계입니다. 규칙상 `legal_calculation_object`는 linked evidence의 `legal_calculation_object` 내부 값에서만 병합하고, `BO 본문만으로 새 계산필드를 만들지 않는다`, `linked evidence 밖의 다른 증거를 섞지 않는다`고 되어 있습니다. 이 설계 때문에 event-level에서 얻은 구조가 사실원장에서 다시 문서 단위 대표값에 종속됩니다. 

### 반드시 바꿔야 할 방향

Task_D1은 아래처럼 바뀌어야 합니다.

* `Fact_Ledger_base.json`의 계산객체는 **BO에 연결된 event-level calculation object를 1차 소스**로 한다.
* linked evidence의 document-level calculation object는 **부족한 필드 보충용 2차 소스**로만 사용한다.
* `BO.Action`, `BO.Object`, `Evidence[].relevant_content`가 특정 거래유형·금액·등기객체를 직접 가리키고, event-level calculation object와 합치할 때는 이를 사용해 계산객체를 **정합성 검증**할 수 있다.
* “BO 본문만으로 새 계산필드를 만들지 않는다”는 금지는 유지하되, **event-level source가 명시적으로 존재하는데 document-level fallback이 다르게 말하는 경우에는 event-level을 살리는 방향**으로 수정해야 한다.

즉, “창작 금지”는 유지하되 “정합한 event-level 복원까지 금지”하면 안 됩니다.

---

## 5. `1 BO = 1 Fact`는 유지하되, `1 BO = 1 calculation source`라는 암묵적 전제를 깨야 한다

현재 Task_D1의 `1 BO = 1 Fact` 원칙 자체는 문제가 아닙니다. 문제는 그 옆에 사실상 붙어 있는 암묵 규칙, 즉 **“1 BO는 linked document의 대표 calculation object 하나를 상속한다”**는 관행입니다. 

### 반드시 바꿔야 할 점

Stage 1 프롬프트 전반에 다음 원칙을 명문화해야 합니다.

* `1 BO = 1 Fact`는 유지한다.
* 그러나 BO/Fact가 상속하는 계산정보는 **문서 대표값이 아니라 해당 BO를 발생시킨 사건행위(event) 단위 값**이다.
* 동일 문서에서 파생된 서로 다른 BO들끼리는 calculation field를 공유하지 않는다.
* 같은 `Evidence[].evidence_index`를 참조하더라도, `relevant_content`와 `object_spec`, `action_label`이 다르면 다른 calculation cluster로 본다.

이 원칙이 없으면 “같은 문서 E-006을 증거로 쓰는 bh32와 bh33이 같은 계산객체를 나눠 가짐” 같은 문제가 계속 생깁니다. 실제 bh32는 임대차 BO이고 bh33은 매매 BO인데, 둘 다 E-006을 연결합니다. 

---

## 6. Task_B1의 `key_facts` 요약 중심 구조를 줄이고, “문서 내 복수 법률관계 존재 여부”를 명시하는 필드를 넣어야 한다

현재 `evidence_indexed.json`은 `key_facts`에 최대 3개까지 핵심 요약을 넣습니다. 이는 browsing이나 catalog 용도에는 좋지만, downstream에서 “이 문서가 단일 거래문서인지, 복합 문서인지”를 판별하는 데는 부족합니다. E-006은 `key_facts`로 임대차와 매매를 같이 적고 있어 복합 문서라는 사실은 드러나지만, 그 복합성이 **기계적으로 강제되지 않습니다**. 

### 반드시 추가해야 할 필드

Task_B1에 다음 필드를 넣어야 합니다.

* `contains_multiple_legal_events: boolean`
* `event_cluster_count: number`
* `event_cluster_labels: string[]`
* `mixed_object_types: boolean`
* `mixed_rights_types: boolean`

예를 들어 E-006은 적어도 다음과 같이 표시되어야 합니다.

* `contains_multiple_legal_events = true`
* `event_cluster_count = 2`
* `event_cluster_labels = ["임대차", "매매"]`
* `mixed_object_types = true`
  (대지 vs 건물)
* `mixed_rights_types = true`
  (채권행위로서 임대차 vs 처분행위로서 매매)

이 플래그가 있어야 Task_C와 Task_D1이 “문서 대표값을 그대로 퍼오면 위험한 문서”를 사전에 경계할 수 있습니다.

---

## 7. Task_B2의 event candidate에 `source_locator_scope`를 넣어 “문서 내 어느 부분에서 파생되었는지”를 고정해야 한다

현재 Task_B2는 `support_locators`를 남기지만, 이것은 설명용 locator에 가깝고 downstream에서 “두 event가 서로 다른 조항에 기반한다”는 것을 계산적으로 강제하는 수준은 아닙니다. 

### 반드시 추가해야 할 필드

각 event candidate에 다음을 넣어야 합니다.

* `source_locator_scope`

  * `section_id_or_heading`
  * `table_row_id`
  * `paragraph_span`
  * `clause_label`
  * `exclusive_scope_key`

예컨대 E-006의 경우:

* 임대차 event는 `clause_label="제1조"`
* 매매 event는 `clause_label="제2조"`

그리고 각 event마다 `exclusive_scope_key`를 달아야 합니다. 그러면 downstream이 같은 문서라도 다른 clause에 기반한 event를 구별하여 계산정보를 연결할 수 있습니다.

---

## 8. Task_C의 BO 생성 시 `Evidence[].relevant_content`를 단서 수준이 아니라 “event anchor” 수준으로 강화해야 한다

현재 Task_C는 `Evidence[].relevant_content`를 80자 이하의 짧은 핵심 단서로만 적게 합니다. 이 규칙 자체는 과도한 인용 방지에 유용하지만, 너무 짧으면 downstream이 어떤 event였는지 다시 잃어버립니다. 

### 반드시 바꿔야 할 규칙

* `Evidence[].relevant_content`는 단순 축약문이 아니라, **해당 BO를 식별하는 최소 event anchor**여야 한다.
* 특히 하나의 문서가 복수 event를 포함하는 경우, `relevant_content`에는 반드시 아래 세 요소 중 둘 이상이 포함되어야 한다.

  * 행위유형
  * 목적물
  * 핵심 금액 또는 부담
  * 조항 또는 표 행 식별자

예컨대 bh32는
“대지 임대 / 보증금 3억 / 월 300만 / 제1조”
수준으로 적혀야 하고, bh33은
“건물 매매 / 대금 2억 / 제2조”
수준으로 적혀야 합니다.

이렇게 해야 Task_D1이 event-level source를 따라갈 수 있습니다.

---

## 9. Task_D1에 “linked evidence selection by event compatibility” 규칙을 넣어야 한다

현재 Task_D1의 linked evidence 정렬은 `content_relevance`, `doc_type`, `evidence_index`만 봅니다. 그러나 이 기준만으로는 **같은 문서 안의 다른 event cluster**를 구별하지 못합니다. 

### 반드시 추가해야 할 규칙

Fact 생성 시 linked evidence를 고를 때 다음 우선순위를 추가해야 합니다.

1. BO의 `Action`/`Object`와 event-level `event_kind`, `object_spec`, `amount`, `source_locator_scope`가 일치하는 evidence fragment
2. 같은 문서라도 BO의 `relevant_content`와 clause/section이 일치하는 fragment
3. 그 다음에야 기존 `content_relevance`, `doc_type`, `evidence_index`

즉, linked evidence 정렬에서 **event compatibility**가 최우선이어야 합니다. 그렇지 않으면 같은 E-006을 달고 있는 bh32, bh33이 다시 뒤섞입니다.

---

## 10. Task_B1의 `legal_calculation_object` 스키마를 임대차·담보·점유까지 확장해야 한다

현재 Task_B1의 `legal_calculation_object`는 부동산 처분 중심입니다. `transaction_type`, `sale_price`, `registration_date`, `market_value`는 있으나, 임대차의 핵심 값인 보증금·차임·점유개시·임대기간, 담보의 핵심 값인 담보권자·순위·채권최고액·피담보채무 성격 등이 충분히 구조화되어 있지 않습니다. 그러니 downstream은 매매 계열을 과대대표하고, 임대차나 점유·사용수익 계열을 충분히 구조화하지 못합니다. 

### 반드시 넣어야 할 필드

적어도 아래는 event-level 기준으로 구조화되어야 합니다.

* 임대차

  * `lease_deposit_amount`
  * `monthly_rent_amount`
  * `lease_start_date`
  * `lease_end_date`
  * `leased_object_type`
  * `lessor`
  * `lessee`
* 담보

  * `encumbrance_kind`
  * `encumbrance_holder`
  * `encumbrance_rank`
  * `registered_max_amount`
  * `secured_debt_type`
* 점유/인도

  * `possessor`
  * `occupation_basis`
  * `delivery_status`
  * `delivery_order_date`

이 구조가 있어야 Stage 2가 `부당이득반환청구`, `건물인도`, `토지인도`, `임차권확인`, `근저당권설정등기말소`를 병렬적으로 제대로 검토할 수 있습니다.

---

## 11. Task_C에서 meeting-based BO와 evidence-based BO를 합칠 때, event identity를 더 엄격히 써야 한다

현재 Task_C는 `event_kind`, 핵심 actor, 상대방, 목적물, 날짜, `identity_signature`를 보고 BO를 통합합니다. 그런데 `identity_signature`는 현재 `(event_kind + actor + counterparty + object_spec/amount + date)` 수준이라, 같은 문서 안의 복수 transaction cluster를 충분히 강하게 분리하지 못할 수 있습니다. 

### 반드시 수정해야 할 부분

`identity_signature` 또는 그 downstream 활용 규칙에 다음 요소를 추가해야 합니다.

* `object_class`
  (토지 / 건물 / 지분 / 채권 / 담보 / 임대차권)
* `source_locator_scope.exclusive_scope_key`
* `transaction_cluster_id`

즉,
`임대차|이문호|박성희|성수동 대지|2024-11-20|제1조`
와
`처분|이문호|박성희|성수동 상가|2024-11-20|제2조`
가 완전히 다른 cluster로 고정되어야 합니다.

---

## 12. Task_D1의 `amount` 선택 규칙에서 “부동산 처분행위 -> sale_price”의 기계적 연결을 제한해야 한다

현재 D1은 amount를 정할 때 linked evidence의 `sale_price`를 꽤 강하게 참조하도록 설계되어 있습니다. 이 때문에 임대차 fact처럼 원래는 보증금이 대표금액이어야 하는 경우에도 문서 대표값이 매매대금이면 잘못된 amount 상속이 벌어질 위험이 큽니다. 

### 반드시 바꿔야 할 규칙

* `sale_price`는 **BO가 처분/매매/양도/증여/대물변제 event와 event-level로 호환될 때만** 쓸 수 있다.
* 임대차 BO에서는 `lease_deposit_amount`, `monthly_rent_amount`가 `sale_price`보다 절대적으로 우선한다.
* 담보 BO에서는 `claim_secured_cap_amount` 또는 `registered_max_amount`가 우선한다.
* 점유/인도 BO에서는 대표금액을 원칙적으로 비워 두고, 임의로 `sale_price`를 끌어오지 않는다.

즉, amount 규칙이 event semantic과 결합되어야 합니다.

---

## 13. Stage 1 전체에 “문서-수준 authority”와 “event-수준 authority”를 분리하는 총칙을 넣어야 한다

현재 구조는 authority 개념이 문서 카탈로그 쪽으로 과도하게 쏠려 있습니다. `evidence_indexed.json`이 “authority catalog”로 정의되어 있고, 이후 단계들이 이를 강하게 참조합니다. 그런데 authority가 문서 식별에 대해서는 맞지만, **사건행위별 계산정보 authority까지 문서에 몰아준 것**이 문제입니다. 

### 반드시 넣어야 할 총칙

Stage 1 상단 또는 Task_B1/B2/C/D1 공통 규율에 다음을 넣어야 합니다.

* 문서 식별(authority of document identity)은 `evidence_indexed.json`이 가진다.
* 사건행위 식별(authority of event identity)은 `evidence_event_candidates.json`이 가진다.
* 사건행위별 계산정보(authority of event-level calculation)는 event candidate 또는 BO-level structured fields가 가진다.
* 문서-level calculation object는 event-level calculation object를 대체하지 못한다.
* downstream은 event-level authority가 존재하면 이를 우선 사용해야 한다.

이 한 문단이 없으면 각 task가 각자 자기 논리로 문서-level과 event-level을 섞어 쓰게 됩니다.

---

## 14. Task_B1에서 “복합 문서의 경우 가장 직접적인 1개만 남긴다”는 사고방식 자체를 버려야 한다

현재 B1은 후보가 둘 이상이면 가장 직접적인 1개만 남기라고 합니다. 이것은 거래문서가 단일 거래를 담고 있다는 전제를 깔고 있습니다. 그러나 실제 민사사건 문서는 복합 문서가 흔합니다. 매매+점유이전+임대차 승계+부담 인수+담보 말소 협조 같은 조합은 매우 일반적입니다.

### 반드시 바꿔야 할 원칙

다음과 같이 사고방식을 전환해야 합니다.

* 복합 문서는 예외가 아니라 통상적 가능성으로 본다.
* “가장 직접적인 1개”를 선택하는 것이 아니라, **서로 다른 권리변동 cluster를 빠짐없이 식별**한다.
* 여러 cluster가 있으면 요약 필드가 아니라 **분리된 구조체로 보존**한다.
* downstream 편의를 위해 정보를 버리는 것보다, downstream이 명시적으로 고를 수 있도록 남기는 쪽을 우선한다.

---

## 15. `client_meeting.md`를 B1에서 “문서-level shorthand 보정” 용도로만 쓰지 말고, event disambiguation 보조에도 쓰게 해야 한다

현재 B1은 `client_meeting.md` 사용 허용 필드를 매우 제한적으로 두고 있습니다. 이는 hallucination을 막는 데는 유리하지만, 복합 문서에서 어떤 조항이 어떤 사건 cluster에 대응하는지 판별하는 데는 지나치게 인색합니다. 

### 반드시 바꿔야 할 규칙

`client_meeting.md`는 사건 사실 창작의 근거가 되어서는 안 되지만, 다음 용도로는 명시적으로 허용해야 합니다.

* 동일 문서 내 복수 목적물 구분
* 동일 당사자 사이 복수 법률관계 구분
* shorthand의 목적물 매핑
* 동일 날짜 복수 거래의 cluster 분리
* 건물/토지/지분/임차권/근저당권의 객체 클래스 판정 보조

즉, meeting은 새 사실을 만드는 용도가 아니라 **event disambiguation** 용도로 써야 합니다.

---

## 16. BO 생성 시 “문서에서 직접 읽히는 사건행위”와 “의뢰인 진술로 보강된 사건행위”를 분리하는 더 강한 표지가 필요하다

현재 BO는 `StatementType="주장"` 또는 `증거`로 구분되지만, 계산정보 상속 단계에서는 이 구분이 충분히 강하게 작동하지 않습니다. 그 결과 evidence-only fact와 meeting-based fact가 같은 document-level metadata를 나눠 가질 수 있습니다. 

### 반드시 추가해야 할 필드

BO 또는 Fact에 다음이 필요합니다.

* `fact_origin = "meeting_only" | "evidence_only" | "meeting+evidence"`
* `calculation_origin = "event_evidence" | "document_evidence" | "meeting_inferred_prohibited"`
* `cluster_confidence = "high" | "medium" | "low"`

이 필드가 있으면 downstream에서 “지금 이 값은 문서-level fallback인지, event-level direct extraction인지”를 명시적으로 알 수 있습니다.

---

## 17. Stage 1에서 “등기문서 성격 우선” 규칙을 너무 강하게 쓰는 부분을 제한해야 한다

현재 D1은 등기문서가 있으면 등록일, 거래유형 등을 우선적으로 가져오게 설계되어 있습니다. 이 자체는 등기 말소 사건에서는 필요하지만, 다른 사건행위의 계산정보를 덮어쓰는 원인이 되기도 합니다. 예컨대 증여 BO가 후행 경매 등기정보를 잘못 상속하는 식의 문제가 이미 관찰되었습니다. 

### 반드시 바꿔야 할 점

* 등기문서 우선 규칙은 **등기행위 BO에 한정**해야 한다.
* 매매 BO, 임대차 BO, 증여 BO, 채무승인 BO 등에 대해서는 등기문서 필드가 자동 우선하지 않도록 제한해야 한다.
* `registration_date`나 `transaction_type="매매"`는 BO의 `event_kind` 및 `JuristicAct.label`과 호환되는 경우에만 채택해야 한다.

---

## 18. Task_D1의 “linked evidence 밖의 다른 증거를 섞지 않는다”는 금지는 유지하되, “같은 BO를 발생시킨 event fragment”는 같은 evidence로 간주하도록 정의를 바꿔야 한다

현재 이 금지는 전체적으로 맞는 방향입니다. 그러나 같은 문서 안의 다른 fragment를 아예 동일하게 취급해 버리는 것이 문제입니다. 따라서 금지 규칙 자체가 아니라 “linked evidence”의 정의를 고쳐야 합니다.

### 반드시 바꿔야 할 정의

* linked evidence는 단순 `evidence_index` 일치가 아니라,

  * `evidence_index`
  * `source_locator_scope`
  * `relevant_content`
  * `event_cluster_id`
    의 결합으로 정의한다.
* 따라서 같은 E-006이라도 bh32와 bh33은 서로 다른 linked evidence fragment를 참조하는 것으로 본다.

이렇게 해야 “다른 문서를 끌어와 섞지 않는다”는 금지를 유지하면서도, 같은 문서 내 event 오염을 막을 수 있습니다.

---

## 19. 최종적으로는 `evidence_indexed.json`을 slim catalog로, `evidence_event_candidates.json`을 rich structured source로 재설계해야 한다

이것은 개별 규칙이 아니라 전체 아키텍처 수준의 수정입니다.

현재는:

* B1 = authority catalog + 일부 계산객체
* B2 = event candidate
* C/D1 = 다시 B1 계산객체를 강하게 사용

이 구조입니다.

### 반드시 바뀌어야 할 목표 구조

* **B1 (`evidence_indexed.json`)**
  문서 카탈로그 전용
  → 문서 식별, 문서 타입, 문서 요약, source pointer
* **B2 (`evidence_event_candidates.json`)**
  사건행위 authority 전용
  → event identity + event-level calculation + locator scope
* **C (`BO.json`)**
  event authority를 1차로 사용하는 사건 구조화
* **D1 (`Fact_Ledger_base.json`)**
  BO를 그대로 ledger로 옮기되 event-level calculation을 보존

이 방향으로 구조를 재설계해야 합니다. 그렇지 않으면 Stage 2 이전에 이미 정보 손실이 일어납니다.

---

# 최종 정리

Stage 1에서 반드시 고쳐야 할 규칙들을 압축하면 다음과 같습니다.

1. **문서 단위 단일 `legal_calculation_object` 규칙 폐기**
2. **event candidate에 event-level calculation object 필수화**
3. **Task_C가 event-level calculation을 1차 소스로 사용하도록 변경**
4. **Task_D1의 document-level calculation-only 병합 규칙 수정**
5. **`1 BO = 1 Fact`는 유지하되, 계산정보는 event 단위로 상속**
6. **복합 문서 여부를 명시하는 structural flags 추가**
7. **event마다 clause/section 단위 scope key 부여**
8. **`Evidence[].relevant_content`를 event anchor 수준으로 강화**
9. **linked evidence 정렬에 event compatibility 추가**
10. **임대차·담보·점유 필드를 계산객체에 본격 구조화**
11. **identity/signature에 object class와 locator scope 반영**
12. **amount 선택 규칙을 event semantic 기반으로 수정**
13. **문서 authority와 event authority를 명시적으로 분리**
14. **“가장 직접적인 1개만 남긴다”는 사고방식 폐기**
15. **`client_meeting.md`를 event disambiguation 보조에 허용**
16. **fact/calculation origin 표지 추가**
17. **등기문서 우선 규칙을 등기행위 BO로 제한**
18. **linked evidence 정의를 `evidence_index + fragment` 수준으로 재정의**
19. **B1 slim / B2 rich 구조로 아키텍처 재설계**

이 가운데 가장 시급한 것은 1, 2, 3, 4입니다.
이 네 가지를 고치지 않으면, 나머지 보정은 모두 부분적 패치에 그칠 가능성이 큽니다.


------------------------------------------

## 질문:

위 19개 항목을 실제 Stage 1 프롬프트 문장으로 어떻게 수정해야 하는지를 task별로 조문 형태로 최대한 자세하게 작성하라. 

-------------------------------------------

## 답변:

그렇다면 아래와 같이 정리하는 것이 가장 실무적입니다.

이번 답변은 **“Stage 1의 각 task 프롬프트를 실제로 어떻게 고쳐 써야 하는가”**를 목표로,
가능한 한 바로 YAML 프롬프트에 삽입할 수 있는 **조문형 문장**으로 작성하겠습니다.

핵심 전제는 이미 확인된 바와 같습니다.
현재 `Task_B1`은 문서 단위 `legal_calculation_object`를 1개만 허용하고, `Task_B2`는 사건행위를 event-level로 분해하며, `Task_D1`은 다시 linked evidence의 문서 단위 `legal_calculation_object`만 Fact에 병합합니다. 이 구조 때문에 E-006처럼 한 문서에 `임대차`와 `매매`가 함께 있을 때 event-level 분해가 downstream에서 다시 납작해집니다. 실제 E-006은 `evidence_event_candidates.json`에서는 `성수동 대지 임대차`와 `성수동 상가 매매`로 나뉘어 있으나, `evidence_indexed.json`에서는 문서 단위 `legal_calculation_object`가 `매매` 하나로만 남아 있습니다.  
또 `Task_D1`은 base `legal_calculation_object`의 각 필드를 linked evidence의 `legal_calculation_object` 내부 값에서만 가져오라고 명시하고 있습니다.

따라서 아래 수정안은 단순한 문구 손질이 아니라, **Stage 1 데이터 계약의 재설계안**입니다.

---

# I. Stage 1 전체 공통 총칙에 추가할 조문

이 부분은 각 task 앞 공통 블록 또는 `stage1_사건개요파악` 상단 공통 규율로 넣는 것이 좋습니다.

## [공통 신설조문 1] 문서 authority와 사건행위 authority의 분리

**추가 문안**

> ## 공통 구조 원칙 (Document Authority vs Event Authority)
>
> * `evidence_indexed.json`은 문서 식별과 문서 요약의 authority catalog다.
> * `evidence_event_candidates.json`은 사건행위(event) 식별과 사건행위별 구조화 정보의 authority ledger다.
> * 문서 단위 정보는 사건행위별 정보를 대체하지 못한다.
> * 동일 문서에서 복수의 법적 중요 사건행위가 식별되면, 후속 단계는 반드시 사건행위 단위 authority를 우선 사용해야 한다.
> * 문서 단위 요약 또는 문서 단위 metadata는 event-level 정보가 없을 때에만 fallback으로 사용할 수 있다.

## [공통 신설조문 2] 복합 문서에 대한 원칙

**추가 문안**

> ## 공통 복합문서 처리 원칙
>
> * 한 문서에 둘 이상의 권리변동, 의무발생, 담보설정, 임대차, 처분, 지급, 통지, 등기 관련 사건행위가 함께 존재할 수 있음을 전제로 처리한다.
> * 복합 문서는 예외가 아니라 통상 가능한 사례로 본다.
> * 복합 문서에 대해 “가장 직접적인 1개만 남기는” 방식으로 정보를 축약해서는 안 된다.
> * 서로 다른 목적물, 서로 다른 권리객체, 서로 다른 조항, 서로 다른 거래유형에 대응하는 사건행위는 반드시 별도 cluster로 보존한다.

## [공통 신설조문 3] event-level calculation 우선 원칙

**추가 문안**

> ## 공통 계산정보 우선순위 원칙
>
> * 거래유형, 대가, 등기일자, 담보정보, 임대차 조건, 점유·인도 상태, 시가 등 계산 또는 법률효과에 직접 연결되는 구조화 정보는 사건행위(event) 단위로 귀속시키는 것을 원칙으로 한다.
> * 문서 단위 계산정보는 event-level 계산정보가 존재하지 않을 때에만 제한적으로 사용할 수 있다.
> * 동일 문서 안의 다른 사건행위에서 추출된 계산정보를 현재 사건행위에 상속하거나 공유해서는 안 된다.

---

# II. Task_B1 개정안

현재 Task_B1은 `evidence_indexed.json`을 authority catalog로 만들면서 문서당 하나의 `legal_calculation_object`를 저장하도록 설계되어 있습니다. 이 부분을 가장 크게 바꿔야 합니다. 현재 스키마에는 문서 단위 `legal_calculation_object`가 포함되어 있고, 추가 제약으로 빈 객체 금지와 문서당 포함 여부만 관리합니다. 

아래는 **Task_B1 프롬프트에 실제로 넣을 수정 조문**입니다.

---

## [Task_B1 개정조문 1] 문서당 단일 `legal_calculation_object` 규칙 삭제

**기존 취지 폐기 대상**

* “문서당 0개 또는 1개만 허용”
* “후보가 둘 이상이면 가장 직접적인 1개만 남긴다”

**대체 문안**

> ## 9) `legal_calculation_object` 관련 핵심 변경
>
> * 더 이상 문서당 단일 `legal_calculation_object`를 생성하지 않는다.
> * `evidence_indexed.json`은 authority catalog이며, 문서 식별과 문서 개요를 위한 정보만 저장한다.
> * 계산 또는 법률효과와 직접 연결되는 세부 구조화 정보는 원칙적으로 `Task_B2`의 event-level 구조에서 생성한다.
> * 따라서 `evidence_indexed.json`에는 문서 전체를 대표하는 `transaction_type`, `sale_price`, `registration_date`, `market_value_at_act`, `market_value_at_close`, `consideration_breakdown`를 단일 객체로 고정 저장하지 않는다.

---

## [Task_B1 개정조문 2] `evidence_indexed.json`은 slim catalog로 제한

**추가 문안**

> ## 9-1) B1 산출물의 역할 제한
>
> * `evidence_indexed.json`은 문서 catalog다.
> * 이 파일의 목적은 `evidence_index`, `doc_uid`, `title`, `doc_type`, `key_facts`, `key_dates`, `key_amounts`, `key_parties`, `source_pointer`를 안정적으로 부여하는 데 있다.
> * 이 파일은 사건행위별 거래유형 또는 사건행위별 계산정보의 authority가 아니다.
> * 문서 요약만으로 사건행위 단위 법률효과를 대표시키지 않는다.

---

## [Task_B1 개정조문 3] 복합 문서 플래그 신설

**추가 문안**

> ## 9-2) 복합 문서 표시 필드
>
> 각 문서에 아래 필드를 추가할 수 있다.
>
> * `contains_multiple_legal_events`: boolean
> * `event_cluster_count`: number
> * `event_cluster_labels`: string[]
> * `mixed_object_types`: boolean
> * `mixed_rights_types`: boolean
>
> 규칙:
>
> * 하나의 문서에서 임대차와 매매, 담보설정과 소유권이전, 점유와 처분, 지급과 채무인정 등 둘 이상의 법적 중요 사건행위가 직접 읽히면 `contains_multiple_legal_events=true`로 한다.
> * 서로 다른 목적물 또는 서로 다른 객체 클래스(예: 토지/건물, 채권/담보권)가 함께 나타나면 `mixed_object_types=true`로 한다.
> * 서로 다른 권리유형(예: 임대차/매매/담보설정)이 함께 나타나면 `mixed_rights_types=true`로 한다.
> * 이 필드는 후속 단계가 문서 단위 flattening 위험을 감지하는 용도로 사용한다.

---

## [Task_B1 개정조문 4] 문서-level 계산정보는 “대표값”이 아니라 “있더라도 참고메모”만 허용

가장 엄격하게 가려면 문서-level 계산객체를 완전히 없애는 것이 최선입니다.
다만 하위 호환성을 고려해 남기려면 아래처럼 바꿔야 합니다.

**추가 문안**

> ## 9-3) 문서-level 계산정보의 제한적 보존
>
> * 하위 호환을 위해 문서-level 계산정보를 유지할 필요가 있는 경우에도, 이는 `document_level_notes_for_event_disambiguation` 성격의 보조 필드여야 한다.
> * 문서-level 계산정보는 후속 단계에서 event-level 계산정보보다 우선할 수 없다.
> * 복합 문서(`contains_multiple_legal_events=true`)에서는 문서-level 계산정보를 대표 거래유형으로 사용하지 않는다.
> * 복합 문서에서 단일 `transaction_type`, 단일 `sale_price`, 단일 `registration_date`를 문서 전체 representative value로 확정 저장하는 것은 금지한다.

---

## [Task_B1 개정조문 5] client_meeting.md 사용 범위 확대 — event disambiguation 허용

현재 B1은 `client_meeting.md`를 자산 식별과 shorthand 해석 수준으로만 제한하는 경향이 강합니다. 이를 조금 넓혀야 합니다.

**추가 문안**

> ## 6-1) `client_meeting.md` 사용 허용 범위 확장
>
> `client_meeting.md`는 아래 목적에 한해 보조적으로 사용할 수 있다.
>
> * 동일 문서 내 복수 목적물의 구분
> * 동일 당사자 사이 복수 거래관계의 구분
> * shorthand 또는 축약 표기의 목적물 매핑
> * 토지/건물/지분/채권/담보권/임차권의 객체 클래스 판정 보조
> * 같은 날짜에 존재하는 복수 거래 cluster의 구분
>
> 단:
>
> * `client_meeting.md`만으로 문서에 없는 새 사건행위를 생성해서는 안 된다.
> * `client_meeting.md`는 event disambiguation 보조에만 사용한다.

---

## [Task_B1 개정조문 6] 출력 스키마 개정

기존 스키마에서 문서-level `legal_calculation_object`를 제거하거나 최소화해야 합니다.

**권장 새 스키마 문안**

> ## 10) 출력 스키마 (개정)
>
> 각 원소는 아래 필드만 가진다.
>
> ```json
> {
>   "evidence_index": "E-001",
>   "doc_uid": "DOC-001-...",
>   "title": "...",
>   "title_normalized": "...",
>   "doc_type": "판결/결정|공문서|거래기록|통신기록|처분문서|기타",
>   "key_facts": [],
>   "key_dates": [],
>   "key_amounts": [],
>   "key_parties": [],
>   "contains_multiple_legal_events": false,
>   "event_cluster_count": 1,
>   "event_cluster_labels": [],
>   "mixed_object_types": false,
>   "mixed_rights_types": false,
>   "source_pointer": {
>     "source": "evidence_all.json",
>     "ordinal": 1
>   }
> }
> ```
>
> 추가 규칙:
>
> * 문서-level `legal_calculation_object`는 원칙적으로 출력하지 않는다.
> * 사건행위별 구조화 계산정보는 `Task_B2`에서 생성한다.

---

# III. Task_B2 개정안

이 task가 Stage 1의 핵심이 됩니다. 지금은 event는 분해하지만 계산정보가 없습니다. E-006처럼 임대차와 매매를 잘 분해해도 downstream이 다시 문서-level metadata를 상속합니다. 

따라서 Task_B2는 **event authority + event-level calculation authority**를 함께 가지도록 바꿔야 합니다.

---

## [Task_B2 개정조문 1] event candidate에 `event_legal_calculation_object` 신설

**추가 문안**

> ## 8-1) 사건행위별 계산정보 필드 신설
>
> 각 `event_candidates[]`에는 필요할 때 아래의 `event_legal_calculation_object`를 포함할 수 있다.
>
> ```json
> "event_legal_calculation_object": {
>   "object_class": null,
>   "transaction_type": null,
>   "transaction_date": null,
>   "sale_price": null,
>   "consideration_breakdown": [],
>   "registration_date": null,
>   "registry_office": null,
>   "registry_receipt_no": null,
>   "registry_recorded_transfer_date": null,
>   "lease_deposit_amount": null,
>   "monthly_rent_amount": null,
>   "lease_start_date": null,
>   "lease_end_date": null,
>   "lessor": null,
>   "lessee": null,
>   "encumbrance_kind": null,
>   "encumbrance_holder": null,
>   "encumbrance_rank": null,
>   "registered_max_amount": null,
>   "market_value_at_act": null,
>   "market_value_at_close": null,
>   "possessor": null,
>   "occupation_basis": null,
>   "delivery_status": null
> }
> ```
>
> 규칙:
>
> * 현재 candidate가 직접 보여 주는 사건행위에 대응하는 필드만 채운다.
> * 다른 사건행위에 속하는 금액, 등기, 차임, 담보정보를 현재 candidate에 넣지 않는다.
> * 불명확하면 `null` 또는 `[]`로 둔다.
> * 추론으로 새 거래조건을 창작하지 않는다.

---

## [Task_B2 개정조문 2] event-level calculation은 필수 추출 대상

**추가 문안**

> ## 8-2) event-level calculation 의무 추출 규칙
>
> 아래 범주에 해당하는 candidate는 `event_legal_calculation_object`를 적극적으로 채워야 한다.
>
> * 매매 / 증여 / 대물변제 / 소유권이전 / 처분
> * 임대차
> * 근저당 / 담보설정 / 담보말소
> * 변제 / 배당 / 대위변제 / 구상권 관련 지급
> * 점유 / 인도 / 사용수익 상태가 핵심인 candidate
>
> 예:
>
> * 임대차 candidate에서는 `lease_deposit_amount`, `monthly_rent_amount`, `lessor`, `lessee`를 우선 추출한다.
> * 매매 candidate에서는 `transaction_type`, `sale_price`, `consideration_breakdown`를 우선 추출한다.
> * 담보설정 candidate에서는 `encumbrance_kind`, `encumbrance_holder`, `registered_max_amount`를 우선 추출한다.

---

## [Task_B2 개정조문 3] clause/section 단위 scope 강제

현재 `support_locators`만으로는 downstream이 fragment를 강하게 분리하기 어렵습니다.

**추가 문안**

> ## 8-3) source locator scope 필드 신설
>
> 각 candidate에는 아래의 `source_locator_scope`를 추가할 수 있다.
>
> ```json
> "source_locator_scope": {
>   "section_id_or_heading": null,
>   "clause_label": null,
>   "table_row_id": null,
>   "paragraph_span": null,
>   "exclusive_scope_key": null
> }
> ```
>
> 규칙:
>
> * 동일 문서 안의 서로 다른 조항, 서로 다른 표 행, 서로 다른 단락에서 파생된 candidate는 서로 다른 `exclusive_scope_key`를 가져야 한다.
> * 복합 문서에서 `exclusive_scope_key`는 필수다.
> * 예: 같은 계약서의 `제1조 임대차`, `제2조 매매`는 반드시 서로 다른 `exclusive_scope_key`를 사용한다.

---

## [Task_B2 개정조문 4] object_class 강제

**추가 문안**

> ## 8-4) 객체 클래스 표준화
>
> `event_legal_calculation_object.object_class`는 가능한 경우 아래 중 하나로 채운다.
>
> * `"토지"`
> * `"건물"`
> * `"토지지분"`
> * `"건물지분"`
> * `"채권"`
> * `"근저당권"`
> * `"임차권"`
> * `"영업자산"`
> * `"기타"`
>
> 규칙:
>
> * 동일 문서에 토지와 건물이 함께 있어도 현재 candidate가 무엇에 관한 것인지 분명히 분리한다.
> * `object_spec`가 지목 또는 구조를 직접 보여 주면 이를 object_class 판정에 반영한다.

---

## [Task_B2 개정조문 5] identity_signature 확장

현재 identity_signature는 object class나 clause 정보를 반영하지 않습니다. 

**대체 문안**

> ## 6. identity_signature 생성 규칙 (개정)
>
> `identity_signature`는 아래 요소를 가능한 범위에서 포함한다.
>
> * `event_kind`
> * 핵심 actor
> * 핵심 counterparty
> * 핵심 object_spec
> * `event_legal_calculation_object.object_class`
> * `event_date`
> * `source_locator_scope.exclusive_scope_key`
>
> 예:
>
> * `임대차|이문호|박성희|성수동 대지|토지|2024-11-20|E-006-CLAUSE-1`
> * `처분|이문호|박성희|성수동 상가|건물|2024-11-20|E-006-CLAUSE-2`
>
> 규칙:
>
> * 동일 문서 안의 다른 사건행위와 충돌하지 않도록 event-level identity를 강화한다.

---

## [Task_B2 개정조문 6] support_locators와 relevant content 강화

**추가 문안**

> ## 8-5) support locator 상세화
>
> `support_locators.excerpt`는 단순한 짧은 인용이 아니라 현재 candidate를 다른 candidate와 구분할 수 있는 최소 사건 anchor여야 한다.
>
> 복합 문서의 경우:
>
> * 행위유형
> * 목적물
> * 핵심 금액 또는 부담
> * 조항 또는 표 행
>
> 중 적어도 2개 이상이 excerpt 또는 locator_hint에 반영되어야 한다.

---

## [Task_B2 개정조문 7] 출력 스키마 개정

**새 스키마 문안**

> ## 8. evidence_event_candidates.json 스키마 (개정)
>
> 각 candidate는 아래 구조를 따른다.
>
> ```json
> {
>   "candidate_id": "E-001-EC-01",
>   "event_kind": "...",
>   "action_type_candidate": "...",
>   "action_summary": "...",
>   "participants": {...},
>   "object_spec": "...",
>   "amount": null,
>   "event_date": null,
>   "time_text": "...",
>   "time_precision": "exact|approximate|range|unknown",
>   "location": null,
>   "legal_keywords": [],
>   "support_locators": [],
>   "source_locator_scope": {
>     "section_id_or_heading": null,
>     "clause_label": null,
>     "table_row_id": null,
>     "paragraph_span": null,
>     "exclusive_scope_key": null
>   },
>   "event_legal_calculation_object": {
>     "object_class": null,
>     "transaction_type": null,
>     "transaction_date": null,
>     "sale_price": null,
>     "consideration_breakdown": [],
>     "registration_date": null,
>     "registry_office": null,
>     "registry_receipt_no": null,
>     "registry_recorded_transfer_date": null,
>     "lease_deposit_amount": null,
>     "monthly_rent_amount": null,
>     "lease_start_date": null,
>     "lease_end_date": null,
>     "lessor": null,
>     "lessee": null,
>     "encumbrance_kind": null,
>     "encumbrance_holder": null,
>     "encumbrance_rank": null,
>     "registered_max_amount": null,
>     "market_value_at_act": null,
>     "market_value_at_close": null,
>     "possessor": null,
>     "occupation_basis": null,
>     "delivery_status": null
>   },
>   "actio_relevance_candidates": {...},
>   "identity_signature": "...",
>   "confidence": "high|medium|low|unknown"
> }
> ```

---

# IV. Task_C 개정안

Task_C는 BO를 만들면서 사건구조를 합성합니다. 이 단계에서 event authority를 1차 소스로 쓰도록 명확히 고쳐야 합니다. 현재 Task_C는 evidence 측 입력을 `evidence_event_candidates.json`과 `evidence_indexed.json`으로 제한하지만, 계산정보 우선순위는 충분히 명시되어 있지 않습니다.

---

## [Task_C 개정조문 1] event-level calculation 1차 소스 명시

**추가 문안**

> ## 4.1 source priority (개정)
>
> * 사건행위의 존재, 당사자 구조, 목적물, 행위유형, 사건행위별 계산정보는 `evidence_event_candidates.json`을 1차 소스로 사용한다.
> * `evidence_indexed.json`은 문서 identity 및 문서 authority 확인용 2차 소스다.
> * 사건행위별 계산정보와 문서-level 요약정보가 충돌하면 사건행위별 계산정보를 우선한다.

---

## [Task_C 개정조문 2] BO별 event anchor 의무화

**추가 문안**

> ## 4.3-1) BO와 event candidate의 1:1 anchor 연결
>
> * evidence 기반 BO를 생성할 때, 각 BO는 반드시 최소 1개의 event candidate에 anchor되어야 한다.
> * 동일 문서에서 복수의 event candidate가 존재하더라도, 현재 BO는 자기와 직접 대응하는 candidate만을 anchor로 삼는다.
> * anchor candidate의 `identity_signature`, `source_locator_scope.exclusive_scope_key`, `event_legal_calculation_object`를 BO 생성의 기준으로 사용한다.
> * 같은 문서의 다른 event candidate에 속하는 계산정보를 현재 BO에 병합해서는 안 된다.

---

## [Task_C 개정조문 3] BO에 계산정보 출처 표지 추가

**추가 문안**

> ## 8-1) BO에 calculation origin 표지 추가
>
> 필요할 경우 아래 필드를 포함할 수 있다.
>
> * `CalculationOrigin`: `"event_evidence"|"document_fallback"|"meeting_only"`
> * `EventAnchorCandidateId`: `"E-###-EC-##"`
> * `EventScopeKey`: `source_locator_scope.exclusive_scope_key`
>
> 규칙:
>
> * event candidate 기반 BO는 원칙적으로 `CalculationOrigin="event_evidence"`로 한다.
> * 문서-level fallback을 사용한 경우에만 `CalculationOrigin="document_fallback"`로 한다.
> * 이 표지는 후속 Task_D1 정규화에 사용된다.

---

## [Task_C 개정조문 4] Evidence[].relevant_content 강화

**기존 80자 규칙 보완 문안**

> ## 7. Evidence 매칭 규칙 (개정 추가)
>
> * `Evidence[].relevant_content`는 짧은 단서 수준이되, 복합 문서에서는 현재 BO를 다른 BO와 구별할 수 있는 사건 anchor를 포함해야 한다.
> * 복합 문서에 연결되는 경우 `relevant_content`에는 가능하면 아래를 반영한다.
>
>   * 행위유형
>   * 목적물
>   * 핵심 금액 또는 차임/담보액
>   * 조항 또는 표 행 단서
> * 예:
>
>   * `"대지 임대, 보증금 3억, 월 300만, 제1조"`
>   * `"건물 매매, 대금 2억, 제2조"`

---

## [Task_C 개정조문 5] identity / merge 규칙 강화

**추가 문안**

> ## 4.3 중복 통합 규칙 (개정 추가)
>
> 동일 사건 여부를 볼 때 아래 요소를 함께 본다.
>
> * `event_kind`
> * 핵심 actor / counterparty
> * `object_spec`
> * `event_legal_calculation_object.object_class`
> * 날짜
> * `identity_signature`
> * `source_locator_scope.exclusive_scope_key`
>
> 규칙:
>
> * 동일 문서라도 `exclusive_scope_key`가 다르면 원칙적으로 다른 사건행위로 본다.
> * 토지와 건물, 임대차와 매매, 처분과 담보설정은 같은 문서에 있어도 자동 병합하지 않는다.

---

## [Task_C 개정조문 6] meeting 기반 보정의 한계 명확화

**추가 문안**

> ## 4.1-1) meeting 보정의 범위
>
> * `client_meeting.md`는 사건 서사, 당사자 관계, 자산 cluster 인식, event disambiguation 보조에 사용한다.
> * 다만 `client_meeting.md`만으로 event-level 계산정보를 새로 만들지 않는다.
> * `client_meeting.md`는 evidence event 간의 구분을 도와주되, 문서에 없는 금액·차임·등기일자를 창작하는 근거가 되어서는 안 된다.

---

# V. Task_B3 개정안

Task_B3는 사해행위 support indexing이지만, 현재도 문서 단위 support를 sparse하게 기록합니다. 이 task는 본질적 병목은 아니지만, event-level scope를 반영해야 후속 Stage 2의 사해행위취소 피고 확장도 더 정확해집니다.

---

## [Task_B3 개정조문 1] support도 event scope와 연결

**추가 문안**

> ## 7-1) actio support의 event scope 연결
>
> 각 `actio_pauliana_support`에는 가능하면 아래 필드를 추가할 수 있다.
>
> * `event_anchor_candidate_ids`: string[]
> * `event_scope_keys`: string[]
>
> 규칙:
>
> * 동일 문서에 복수의 사건행위가 존재할 경우, 현재 support가 직접 연결되는 사건행위 scope만 기록한다.
> * 문서 단위 관련성만으로 다른 사건행위에 support를 전이하지 않는다.

---

## [Task_B3 개정조문 2] 목적물 단위 구분 강화

**추가 문안**

> ## 6.2 fraudulent_act_date 규칙 (개정 추가)
>
> * 같은 문서 안에 복수 목적물 또는 복수 권리객체가 있으면, 현재 support가 연결되는 목적물 cluster가 명확할 때만 `fraudulent_act_date`를 채운다.
> * 다른 목적물의 처분일 또는 다른 사건행위의 이전일을 현재 support에 전이해서는 안 된다.

---

# VI. Task_D1 개정안

현재 D1이 가장 직접적으로 flattening을 고정합니다. `base legal_calculation_object`는 linked evidence의 `legal_calculation_object` 내부 값에서만 가져온다고 되어 있습니다.  이 규칙을 바꾸지 않으면 앞 단을 고쳐도 다시 오염됩니다.

---

## [Task_D1 개정조문 1] linked evidence 정의 변경

**대체 문안**

> ## 9.2 linked evidence lookup (개정)
>
> * `evidence_indexed.json`을 `evidence_index` 기준 해시맵으로 만든다.
> * 그러나 linked evidence는 단순히 `evidence_index` 일치만으로 확정하지 않는다.
> * 각 BO의 `Evidence[]`, `EventAnchorCandidateId`, `EventScopeKey`, `Evidence[].relevant_content`를 함께 보아 현재 BO와 사건행위 단위로 호환되는 evidence fragment를 linked evidence로 본다.
> * 같은 `evidence_index`를 공유하더라도 `EventScopeKey`가 다르면 다른 linked evidence fragment로 취급한다.
> * 동일 문서 안의 다른 사건행위 fragment에서 추출된 계산정보를 현재 Fact에 병합해서는 안 된다.

---

## [Task_D1 개정조문 2] event-level calculation object 우선 사용

**대체 문안**

> ## 10.2 사용 가능한 데이터 원천 (개정)
>
> * base `legal_calculation_object`의 각 필드는 아래 우선순위로 가져온다.
>
>   1. 현재 BO에 직접 anchor된 event candidate의 `event_legal_calculation_object`
>   2. 현재 BO와 사건행위 단위로 호환되는 linked evidence fragment의 구조화 정보
>   3. event-level 정보가 없을 때에만 `evidence_indexed.json`의 문서-level 보조 정보
> * linked evidence 밖의 다른 증거를 섞지 않는다는 원칙은 유지한다.
> * 다만 같은 문서 안에서도 현재 BO와 scope가 다른 사건행위의 계산정보는 linked evidence로 보지 않는다.
> * `key_facts`, `key_dates`, `key_amounts`, `key_parties`만으로 새 계산값을 만들지 않는다.
> * BO의 `Action`, `Subject`만으로 새 계산필드를 창작하지 않는다.
> * 그러나 event-level 구조화 정보가 존재하는 경우 이를 문서-level fallback보다 우선 보존해야 한다.

---

## [Task_D1 개정조문 3] event compatibility를 linked evidence 정렬 최우선으로

**대체 문안**

> ## 9.3 linked evidence 정렬 우선순위 (개정)
>
> 같은 BO의 linked evidence들을 아래 기준으로 정렬한다.
>
> 1. 현재 BO의 `EventScopeKey`, `EventAnchorCandidateId`, `Evidence[].relevant_content`와 사건행위 단위로 가장 잘 일치하는 fragment
> 2. `BO.Evidence[].content_relevance`
>
>    * `"직접"` > `"간접"` > `"불명"` > `"반대"`
> 3. 대응 evidence의 `doc_type`
>
>    * `"처분문서"` > `"공문서"` > `"거래기록"` > `"판결/결정"` > `"통신기록"` > `"기타"`
> 4. `evidence_index` 오름차순
>
> 이 정렬순서는 전체 병합의 기본 우선순위로 사용한다.

---

## [Task_D1 개정조문 4] amount 규칙의 semantic gating

**대체 문안**

> ## 9.4.6 `amount` (개정 추가)
>
> * `amount`는 현재 Fact의 사건행위 의미와 호환되는 금액만 선택한다.
> * 매매/처분/양도/증여/대물변제 관련 Fact에서만 `sale_price`를 후보로 사용할 수 있다.
> * 임대차 Fact에서는 `lease_deposit_amount`와 `monthly_rent_amount`가 `sale_price`보다 우선한다.
> * 담보설정 Fact에서는 `registered_max_amount`, `claim_secured_cap_amount`, `claim_guarantee_limit_amount`가 우선한다.
> * 점유/인도/퇴거 Fact에는 대표금액이 직접 연결되지 않으면 `amount=null`로 둔다.
> * 다른 사건행위의 거래대금을 현재 Fact의 amount로 상속해서는 안 된다.

---

## [Task_D1 개정조문 5] 등기문서 우선 규칙 제한

**대체 문안**

> ## 11.2 B. 등기 전용 필드 (개정 추가)
>
> * 등기 전용 필드는 현재 Fact가 등기행위, 등기말소, 소유권이전등기, 근저당권설정등기 등 등기 자체와 직접 관련될 때 우선 사용한다.
> * 현재 Fact가 임대차, 점유, 사용수익, 건물신축, 단순 지급행위인 경우에는 등기문서 필드를 자동 우선하지 않는다.
> * 후행 등기문서의 `registration_date`나 `transaction_type`가 현재 Fact의 사건행위 유형과 호환되지 않으면 채택하지 않는다.

---

## [Task_D1 개정조문 6] Fact에 origin 표지 추가

**추가 문안**

> ## 14-1) Fact origin 메타 필드
>
> 각 Fact에는 아래 필드를 추가할 수 있다.
>
> * `event_anchor_candidate_id`
> * `event_scope_key`
> * `calculation_origin`
>
> 규칙:
>
> * event candidate 기반으로 계산정보를 가져온 경우 `calculation_origin="event_evidence"`로 한다.
> * 문서-level fallback을 사용한 경우 `calculation_origin="document_fallback"`로 한다.
> * 이 필드는 후속 단계가 문서-level flattening 여부를 감지하는 데 사용한다.

---

# VII. Task_D2 개정안

D2는 actio support normalization 단계입니다. 이 단계도 event scope 오염을 막도록 바꿔야 합니다.

---

## [Task_D2 개정조문 1] BO별 support 병합 시 event scope 일치 요구

**추가 문안**

> ## BO별 support 병합 규칙 (개정 추가)
>
> * 각 BO에 support를 병합할 때는 `Evidence[].evidence_index` 일치만으로 충분하지 않다.
> * `event_scope_key`, `event_anchor_candidate_id`, `relevant_content`, 목적물 cluster가 함께 일치할 때만 해당 support를 현재 BO에 병합한다.
> * 같은 문서의 다른 사건행위에서 파생된 support는 현재 BO에 병합하지 않는다.

---

## [Task_D2 개정조문 2] 목적물 cluster 불일치 시 강제 차단

**추가 문안**

> ## 목적물 cluster 오염 차단 규칙
>
> * support의 목적물 cluster와 현재 BO의 목적물 cluster가 실질적으로 다르면 병합을 금지한다.
> * 토지와 건물, 본체 거래와 담보설정, 임대차와 매매는 같은 문서에 있어도 다른 cluster로 본다.

---

# IX. 가장 중요한 실제 수정 포인트만 다시 압축

실제로 YAML을 수정할 때 제일 먼저 넣어야 하는 것은 아래입니다.

**Task_B1**

* 문서당 단일 `legal_calculation_object` 삭제
* `contains_multiple_legal_events` 등 복합 문서 플래그 추가

**Task_B2**

* `event_legal_calculation_object` 추가
* `source_locator_scope.exclusive_scope_key` 추가
* `identity_signature`에 object_class / scope key 반영

**Task_C**

* event-level calculation을 1차 source로 사용
* BO마다 event anchor 강제

**Task_D1**

* linked evidence 정의를 `evidence_index + event scope` 수준으로 변경
* base `legal_calculation_object`는 event-level source 우선
* amount와 registration 정보에 semantic gating 추가

이 네 축이 바뀌지 않으면, 나머지 보완조문은 효과가 제한적입니다.

